probably redundant as Data layout comment covers this

i left it as easy copy and paste if you need to add new archs. could maybe put it at the end of the file and add a note to the front?

IMO it's easier to copy/paste from an existing configuration. If the configurations were split between multiple files then having a clean reference/blueprint here would be more valuable.

(So I would suggest deleting this comment)

there is some logic to make these keys lowercase (less mistake prone when declaring gpu families). should we make all these keys consistent and lowercase?

I'd go the other way and use uppercase consistently, to match the source of truth in https://github.com/ROCm/TheRock/blob/main/cmake/therock_amdgpu_targets.cmake

super nit and this is just an opinion (don't need to implement): can we order these to match amdgpu_family_predefined_groups's order?

it started like this in the beginning... if moving i would rather move it into numeric ordering? what do you think?

IMO it's easier to copy/paste from an existing configuration. If the configurations were split between multiple files then having a clean reference/blueprint here would be more valuable.

typos here? - and consistent uppercase or lowercase of X?

yeah... i had it capitalized and then let myself convince from geo that lower case is also not a bad choice. i switch it back to "X". matching to the cmake file is definitely what i had on my mind in the original design ... which i then forgot over the last couple of months :(

I'd go the other way and use uppercase consistently, to match the source of truth in https://github.com/ROCm/TheRock/blob/main/cmake/therock_amdgpu_targets.cmake

I don't understand the nesting here. Is this planning towards having e.g.

"gfx103x": {
  "all": { },
  "dgpu": { },
  "igpu": { }
}

?

If we only ever have one at a time, it would be simpler to collapse down a level to just

"gfx103X-all": { },
"gfx103X-dgpu": { },
"gfx103X-igpu": { }

There there wouldn't an extra level of nesting between

    "gfx115x": {
        "gfx1153": {     // <--- single target
            "linux": {
                "build": {
                    "expect_failure": True,
                    "build_variants": ["release"],
                },

    "gfx90x": {
        "dcgpu": {    // <--- family grouping
            "linux": {
                "build": {
                    "build_variants": ["release"],

Comments like this and my previous thought on converting the contents of the matrix in an easier to read format has me thinking that maybe it is worth exploring the reverse. We could define the matrix in format (.yml or ,json for example) that is easier to read and maintain, and then script to consume and test its contents for things we want to standardize like capitalization.

I wonder if this would be easier to maintain and edit if we refactored like so:

amdgpu_family_gfx94X = {
  "dcgpu": {  ... }
}

amdgpu_family_gfx110X = {
  "dcgpu": {  ... }
}

amdgpu_family_info_matrix_all = {
  "gfx94X": amdgpu_family_gfx94X,
  "gfx110X": amdgpu_family_gfx110X,
  ...
}

It would be possible to add a family and then forget to "register" it in the _all list though.

I had some similar thoughts back on #1097 and #1350 .

I don't understand the nesting here.

my idea of the nesting was that everything below "gfx103x" can either be group or arch that are part of "gfx103". just anything matching "gfx103" and adding on demand when needed for the CI.

if we would want to run "igpu", or just the single gpu target "gfx1030" or "gfx1032" we would have the structure like this:

"gfx103x": {
  "all": { },
  "dgpu": { },
  "igpu": { },
  "gfx1030": { }.
   "gfx1032": { }
}

thinking about it having separate files for better editing:
we could have

amdgpu_family_matrix.py
amdgpu_family_gfx103x.py
amdgpu_family_gfx950.py
amdgpu_family_gfx94x.py
...

in which we do the same trick as we do for the pytorch skip testing:

• all amdgpu_family_gfx<family>.py have the same dictionary name: amdgpu_family_info
• amdgpu_family_matrix.py builds amdgpu_family_info_matrix_all by importing all amdgpu_family_gfx*.py files and adding the specific amdgpu_family_info to amdgpu_family_info_matrix_all

structure within amdgpu_family_gfx<family>.py would be:

amdgpu_family_info = {
  "gfx103x": {
    "all": { },
    "dgpu": { },
    "igpu": { },
    "gfx1030": { }.
     "gfx1032": { }
  }
}

maybe having a short call about it would be good?

just as an addition. this is the current plan in my head:

• new structure for amdgpu matrix to know what belongs to build, test, release and be independent of if arch belongs to presubmit, postsubmit or nightly_ci
• new configure_ci ( configure_amdgpu_matrix.py ) that allows for default values for each configuration step and removes entire matrices that are not required (e.g. no testing wanted = no test section in the matrix returned)
• new setup.yml that propagates the container image to only have to set the image at a single place
• add weekly ci
• starting to move over the other cis to use the new layout (should be easy as the only the toplevel workflow elements need to be changed)
• add multi arch generator in configure_amdgpu_matrix.py
• looking then if and how the rest of the configurators (fetch_.. , configure_...,) etc can be integrated into configure_amdgpu_matrix.py
• finish moving all cis to the new format

(So I would suggest deleting this comment)

nit: add a trailing comma after bypass_tests_for_releases so this wraps like the other entries

i blame pre commit hook :-P